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PROPOSED TELECONFERENCE AGENDA 
FROM JIM BOICE (512.617.5533) 
09/918,132 
AFTER-FINAL 

Claim 1, 

Can we discuss the feature of "in response to determining that said firmware 
family codes are different, considering said two firmware images to be incompatible 
unless a compatibility table entry indicates otherwise"? The cited art does not appear to 
teach an overriding "compatibility table entry" that indicates that two firmware images 
are compatible, despite being from different families. 

Furtney teaches the use of compatibility tables for software modules. However, 
In col 4, lines 8-15, different versions of software are considered compatible if the new 
version is at a higher level. Specifically, Furtney states at col. 4: 

In the preferred embodiment, it is assumed that a software module 
at any arbitrary level will include the capabilities and functions of each 
lower level of that same module that are required for compatibility with 
other modules. Thus, for purposes of compatibility, a higher level of a 
module being verified will always satisfy minimum requirements for 
compatibility with the verifying module if any lower level of the module 
being verified satisfies such compatibility requirements. (Emphasis 
added.) 

Thus, there is a presumption in Furtney that two differently named modules ARE 
compatible (assuming that the new version has a higher level), even though they have 
different names. There is no presumption ("in response to... considering") that the two 
versions are incompatible. 



Claim 54 (dependent on Claim 1) 



Can we discuss the feature of "wherein said method for identifying compatibility 
between two firmware images is performed in response to an electronic device having 
undergone a design upgrade that incorporates new components"? That is, firmware 
image compatibility checking is performed whenever a system upgrade of hardware is 
performed. Kathail teaches at col. 25, lines 15-16 that a new set of drivers can be 
introduced for devices, and new drivers can be introduced later (col. 25, lines 20-21). 
However, there does not appear to be a suggestion that compatibility between firmware 
images (not firmware (driver) and device) occur "in response to" new hardware being 
added. 



Claim 35 



Can we discuss the feature of "in response to determining that said installed 
firmware does not have a firmware family control block that includes a firmware family 
code, fimiware stepping level and compatibility table for said installed firmware, causing 
a flash utility to refuse to install said candidate firmware"? The cited art does not appear 
to support this feature of making installation of new firmware dependent upon the old 
firmware having a firmware family control block that specifically includes these three 
elements (firmware family code, stepping level and compatibility table). Kathail is cited 
at col. 24, lines 39-42 for this teaching. However, this passage only teaches that an error 
message should be sent if a compatible driver cannot be found for a specific device, and 
doesn't appear to suggest the claimed limitations. 

Claim 53 (dependent on Claim 35) 

Can we discuss the feature of "in response to determining that said candidate 
firmware is desired to replace said installed firmware that does not have said firmware 
family control block, issuing an override command fi-om said flash utility to override said 
refixse to install command, wherein said candidate firmware flashes over said installed 
flrmware despite said installed firmware lacking said firmware family control block"? 
That is, even if the flash utility has refiised to install the new firmware, an override 
command can be issued forcing the flash utility to install the new firmware anyway. 

Kathail is cited at col. 24, line 55 to col. 25, line 25 for teaching this feature. 
However, this passage appears to be related to matching drivers to devices as soon as the 
driver is accessible on either a hard drive or a boot ROM. I am unable to interpret this 
section as teaching that a flash utility is forced to install new firmware despite its initial 
refiisal to do so (because the firmware didn't have a firmware family block that includes 
a firmware family code, firmware stepping level and compatibility table). 



